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(57) Abstract 

A testing system and method for defining testing scenar- 
ios for a multi-user computer system having a plurality of work- 
stations, and for driving and tracking the execution of the testing 
scenarios in a predefined order at the workstations is disclosed. 
The system and method revolve around the concept of a 
"script". Each script or script set is intended to reflect one busi- 
ness scenario. Each script contains instructions, data, and rout- 
ing information used to execute the testing scenario on the work- 
stations of the multi-user computer system. The testing system 
includes a maintenance and creation means for creating and 
modifying scripts; a tracking administration means for grouping 
selected scripts to form the test, for initiating a lest run, for mon- 
itoring routing of the scripts from workstation to workstation, 
for selectively controlling routing of the scripts from workstation 
to workstation in an error situation, and for automatically gen- 
erating statistical reports detailing the performance of the test; 
and a tracking means for routing the selected scripts to selected 
workstations according to the routing information. 
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SCRIPT-BASED SYSTEM FOR TESTING A MULT I -USER COMPUTER SYSTEM 

This invention relaces generally to the testing of a multi-user 
computer system. More specifically, the invention is concerned with a 
system and method for defining one or more testing scenarios and for 
driving and tracking the execution of the testing scenarios. 
5 Multi-user computer systems are used throughout the business and 

scientific communities to perform a myriad of functions. For example, 
in the business community, computer systems are used to perform 
manufacturing automation, inventory management, order processing and 
tracking, financial accounting, records management, word processing, 

10 etcetera. These functions may be performed company wide on a single 
networked computer system which includes many workstations. The size 
and complexity of such a networked computer system may range from a 
global structure which includes workstations situated at remote sites 
around the world to a local network which includes several workstations 

15 located at a single corporate site. 

An example of one such computer system is SAP (System, . 
Applications and Products in Data Processing) . SAP is a business 
software package consisting of an R/2 Basis System and one or more 
specialized applications modules (for example, financial accounting, 

20 order entry). The R/2 Basis System is a platform on which the various 
applications modules run. The SAP system is available from SAP GmBh, 
Max Planck Strasse 8, D-6909 Walldorf, Germany. 

The SAP system operates in conjunction with a multi-user computer 
system. The term •multi-user* is used herein to mean a computer system 

25 which can simultaneously be used by a plurality of users. A "physical 

workstation" is a "dummy" terminal, a personal computer or any other I/O 
(input/output) device which allows a user to communicate with the 
computer system. A "physical workstation" is also referred co as a 
•terminal". As used herein, the term "logical workstation", or simply, 

30 "workstation" shall mean a functional location which includes one or 
more physical workstations or terminals. Fcr example, an accounting 
department which includes five terminals may be considered a single 
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logical workstation. A logical workstation may also be termed a 'test 
station". The workstations are linked to a central computer (a multi- 
user computer) containing the SAP system. 

In a global business arrangement, for example, a multi-user 
5 computer system may be used to receive a product order at a workstation 
in Paris. The order may result in a request for shipment appearing on a 
workstation in a manufacturing plant in Chicago where the product would 
be produced and shipped. Billing (accounts receivable) processing may 
occur in London on another workstation, while company wide financial 
10 analysis could take place in New York on yet another workstation. Each 
of these business functions would be carried out using various modules 
running within the SAP System. 

Because businesses rely extensively on computer systems, such as 
SAP, it is crucial that the integrity and reliability of these systems 
15 be thoroughly tested prior to total commercial reliance being placed 
thereon. Testing of these complex multi-user systems, however, is 
arduous and complicated due to their immense size, complexity, and 
distributed nature. For example, if it is desired to test the 
functionality of the order entry portion of the SAP system, then it is 
20 preferred to recruit the assistance of a user of that portion of SAP. 
Similarly, if it is desired to test the functionality of the cost 
accounting portion of the SAP system, then it is preferred to recruit 
the assistance of a user of that portion of SAP. However, the person 
desiring to perform the test may be located in the United states while 
25 the order entry user is located at a plant in Europe and the accounting 
user is located at a plant in Canada. This makes the communications and 
coordination between these persons difficult during testing. 

This problem is exacerbated by the fact that the mule i -user 
computer systems require frequent modification/revision to meet the 
10 changing needs of a business. For example, SAP provides several means 
(tools and features) for customizing the system and Cor designing 
customer specific application software and subsystems. These include: 
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ABAP/4 or Advanced Business Application Programming (SAP's 
fourth generation programming language used to create 
transaction programs, utility programs, database queries, 
and other application programs); 

Screen Painter (used to design the online screen layout); 

Dynpro or Dynamic Program (the online screen and the 
processing unique thereto); 

Data Dictionary (a central repository for data definitions 
and meta-data, also used to define fields within a Dynpro); 

Database (holds master file data and transaction data) ; and 

Table (within SAP, tables are used for process control, 
system and screen modification, logic checks and validation 
of data entries, among other things, the benefits of Table 
include the ability to customize SAP without the need to 
programmatically change the system, tables are often created 
in conjunction with customer created applications) . 
Whenever the multi-user computer system is modified, testing is 
required. As discussed above, however, testing such a large system is 
arduous . 

25 The present invention is a computer-based testing system for 

defining and managing a test Cor a multi-user computer system. The 
mult i -user computer system includes a central computer, workstations 
which are coupled to the central computer, and an application (for 
example, SAP) running on the computer system. A test is made up of a 

30 selected group of scripts. Each script contains instructions, data and 
routing information. 

The instructions contained within a script provide step by seep 
directions for an operator at a workstation to conduct a portion of a 
test (execution of a test usually involves many 'test runs"). Each 
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script also concains any daca that the operator will require to carry 
out the instructions. The routing information contained within each 
script indicates to which workstations the script should be routed and 
the order in which the routing should occur. 
5 The present invention includes a maintenance and creation means 

(script maintenance and creation sub-system) for creating and modifying 
scripts. A script administration means (script administration sub- 
system) provides a means for copying and deleting groups of scripts, 
limiting access to scripts and updating groups of scripts. A tracking 

10 means (script tracking sub-system) routes the scripts in a test to the 
appropriate workstations, as set forth in the routing information for 
each script, during a test run. A tracking administration means 
(tracking administration sub-system) provides a means for selectively 
grouping selected scripts to form a test, initiating a test run, 

15 monitoring the transfer of the scripts from workstation to workstation 
during a test run, and automatically documenting the test results. In 
addition, the tracking administration means can control transfer of the 
scripts during an error situation. 

The system and method of the present invention operates in the 

20 following manner. A test administrator utilizes the tracking 

administration sub-system to select a group of scripts which in 
combination will create a test to verify an aspect or function of the 
multi-user computer system. The scripts would have been previously 
created through the use of the script maintenance and creation sub- 

25 system. In addition, each selected script must have been previously 
given an "activated" status through use of the script administration 
sub-system. Each script provides a user of a selected workstation with 
step by step instructions and any data needed to perform a portion of 
the test. 

30 The test administrator initiates the test run. The script 

tracking sub-system routes each script to the appropriate workstation 
for execution. A user at each workstation executes a portion of the 
test in accordance with the instructions contained in the script which 
is routed to the user's workstation. After the user has completed 
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execucion of the script, the script is transferred to the next 
workstation as indicated in the script's routing information. 

The foregoing and other objects, features and advantages should 
become apparent from the following detailed description when taken in 
5 conjunction with the accompanying drawings, in which: 

FIG. 1 is a high level overview of the component parts of a 
preferred embodiment of the present invention; 

FIG. 2 is a high level flow diagram of the interrelationships 
between the main component parts of a preferred embodiment of the 
10 present invention; 

FIG. 3 depicts the general flow of the system for a preferred 
embodiment of the present invention; 

FIG. 4 depicts the initial menu selections available in sub-system 
YSCR in a preferred embodiment of the present invention; 
15 FIG. 5 depicts the menu selections and functions available from 

the BASIC SECTIONS menu in a preferred embodiment of the present 
invention; 

FIG. 6 depicts the menu selections and functions available from 
the OLC (order life cycle) menu in a preferred embodiment of the present 
20 invention; 

FIG. 7 depicts the menu selections and functions available from 
the PIM (plant information management) menu in a preferred embodiment of 
the present invention; 

FIG. 8 depicts the menu selections and functions available from 
25 the FAS (Financial Accounting System) menu in a preferred embodiment of 
the present invention; 

FIG. 9 depicts the menu selections and functions available from 
the UTILITIES menu in a preferred embodiment of the present invention; 

FIG. 10 depicts the initial menu selections available in sub- 
30 system YSCA in a preferred embodiment of the present invention; 

FIG. 11 is a high level flow diagram of the general flow of the 
sub-system YSCA for a preferred embodiment of the present invent ion ; 

FIG. 12 depicts the initial menu selections available in sub- 
system YTRA in a preferred embodiment of the present invention; 
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FIG. 13 is a high level flow diagram of che general flow of the 
sub-system YTRA for a preferred embodiment of the present invention; 

FIG. 14 depicts the initial menu selections available in sub- 
system YTRK in a preferred embodiment of the present invention; and 
5 FIG. 15 is a flow chart which depicts the general methodology of 

script tracking and the execution of a script at a workstation. 



I . OVERVIEW 

a. Introduction 
10 b. Format of a Script 

c. The Data Bases and Tables 

1. Script Header File 112 

2. Script Section File 114 

3. Script Procedures File 116 

15 4. Script Information Control Table 109 

5. Script Tracking Information Table 111 

6. Script Document History Table 113 

7. Workstation Definitions Table 103 

8. Script and Test Status Definitions Table 105 
20 9. Script Test Identifications Table 115 

10. Script Document History Information Table 119 
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12. Script Category Codes Table 107 
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25 

II. SCRIPT MAINTENANCE AND CREATION SUB-SYSTEM (YSCR) 

a. Purpose 

b. Sub-system Functions 

1. Basic Sections 408 
30 2. Order Life Cycle COLC-) Sections 410 

3. Plant Information Management CPIM') Sections 412 

4. Financial Accounting System CFAS") Sections 414 

5. Utilities 406 

c. Script Database Access/Update 
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III. SCRIPT ADMINISTRATION SUB-SYSTEM (YSCA) 

a. Purpose 

b. Sub-system Functions 
5 1 . Overview 

2. Status, Blocking and Categories 

3. Mass Update Functions 

4 . Reports 



10 IV. SCRIPT TRACKING ADMINISTRATION SUB-SYSTEM (YTRA) 

a. Purpose 

b. Sub-system Functions 

c. Operation 



15 V. SCRIPT TRACKING SUB-SYSTEM (YTRK) 

a. Purpose 

b. sub-system Functions 

c. Method of Script Tracking 



2 0 VI. CONCLUSION 



T . OVERVIEW 

a. Introduction 

In general the present invention includes a system and method for 
25 defining fact-based testing scenarios for testing a multi-user computer 
system and for driving and tracking the execution of the testing 
scenarios in a predefined order. In a preferred embodiment of the 
present invention, the testing scenarios are intended to test and verify 
modifications and customized applications in the SAP system described 
30 above. The invention revolves around the concept of a ■script". 

Several related or dependent scripts make up a 'script set". Each 
script or script set is intended to reflect one testing scenario. 

Because the SAP system is a business oriented system, in the 
preferred embodiment of the invention, the fact-based testing scenarios 
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are referred to as 'business scenarios" for ease of reference and a 
script is defined as a document containing instructional information and 
necessary data that when executed (through user interaction with the SAP 
system via a workstation), simulates a business scenario. The system of 
5 che present invention does not directly perform the 'test'. Instead, 

the script provides different users of a multi-user computer system with 
instructions, testing data and expected results which permit the users 
to interact with the system being tested and thereby act out the 
business scenario. In the preferred embodiment, the objective is to 

10 test the functionality of a portion of the SAP system. 

The script data is logically organized into sections that relate 
to workstations in the SAP system being tested. Each workstation in the 
Script Information System (SIS) corresponds to an actual business 
function. As defined above, a 'workstation' (for example, an accounting 

15 department) may include any number of physical workstations (that is, 

terminals). During the execution of a business scenario (for example, a 
script) , a user at each logical workstation executes the section of a 
script pertaining to that workstation. The execution of a section of a 
script involves following the instructions contained in that section of 

20 the script. For example, one section of a script might instruct a 

Customer Service Representative ( - CSR") to enter an order into the SAP 
system at the customer service workstation. The script would also 
provide the CSR with all the necessary order information (data) . 
Another section of the same script might instruct a Shipping Coordinator 

25 CSC) at a shipping workstation to arrange for the transportation of 
the materials needed to fill that order. Again, the script would 
provide the SC with any data that might be required. 

The workstations are defined to the script in a section of the 
script called 'routing". The routing section tells the system the 

30 sequence of workstations which the script will follow. The system then 
monitors the progress of the script along the routing path. A test is 
made up of one or more scripts or script sets. 

For execution of a test, a tester (that is, a user) is assigned to 
each workstation based on his or her area of expertise (for example, 
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order entry, cost accounting, and other specialties). Each tester 
processes his portion of the script. The script is then passed on to 
che next workstation defined in the routing section of the script. When 
a script has been executed at all workstations listed in its routing 
5 section, it has completed a -run'. A test is considered complete when a 
run of the scripts assigned to the test produces no major errors and 
meets the predetermined expecCed results. Many test runs may occur 
during a test, before it is considered complete. 

During the script execution an error may be detected. At that 

10 time the tester for the workstation at which the error is detected 
informs the system that an error is present and, if warranted, che 
scripc is halted until the error is resolved. After the error has been 
resolved, either by system changes or script changes, the script is re- 
entered into the test system according to the routing information. This 

15 is known as an iteration or script cycle. It may take several iterations 
to complete processing of a script within a run. 

A preferred embodiment of the present invention works in 
conjunction with an SIR (System Incident Report) system. The SIR System 
is a problem management system built within SAP technology. The SIR 

20 System is a means for documenting and communicating problems and 

modification within the SAP System. An SIR, which is created using the 
SIR System, contains the information needed for problem and/or 
modification evaluation, prioritization and resolution. The SIR 
System's functions include recording, tracking and aiding in the 

25 management of problems and modifications through various reporting 

capabilities. In a preferred embodiments of the present invention, 
when an error is'detected during the execution of a script, the SIR 
system is utilized to record information pertaining to the error. 

The testing procedure involves the assembly of a tester from each 

30 logical workstation (for example, Order Entry, Order Management, Plant 
Information Management, Order Completion and Accounting) and often from 
different countries into a single location which has been set up with a 
plurality of workstations to simulate a global distributed computer 
system. Each tester runs a specific part of a script routed to his 
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workstation, records the results, and passes the script along to the 
next workstation (as defined by the routing section) until the script is 
completed. If an error occurs, the script may be placed on hold until 
the problem is resolved. 
5 Originally, a script was created and maintained as a paper 

document (similar to an actor's script). The scripts were manually 
maintained, organized and stored in boxes. The testing process required 
that each script be manually passed by the testers from one workstation 
to the next. This required that all testers be located at a single 
10 location {preferably in the same room) . 

Gathering all testers to a single location and manually passing 
scripts between workstations tended to be a tedious, time consuming, and 
expensive undertaking. 

The Script Information System of the invention was developed to 
15 facilitate a more effective and efficient meth^ of creating, 

maintaining, and executing the scripts. The s\ :em eliminates the 
requirement that the testing process be executed in a single 
geographical area and in turn promotes the philosophy of remote testing. 
The Script Information System comprises four components: Script 
20 Maintenance and Creation (YSCR) 102, Script Administration (YSCA) 104, 
Script Tracking (YTRX) 106, and Script Tracking Administration (YTRA) 
108, shown in FIG. 1 . 

In the preferred embodiment of the present invention, SIS is 
designed, developed, and executed within the SAP environment utilizing 
25 the ABAP/4 language. All four components are integrated and utilize 
script information that is stored on three SAP databases. There are 
also SAP tables which support all of the activities of the SIS sub- 
systems or components. The purpose and structure of the data bases and 
tables are detailed in later sections. 
J0 ^ a preferred embodiment of the present invention, the Scripts 

Information System runs on the same multi-user computer system that is 
being tested. However, the Scripts Information System may also be 
implemented on a separate computer system. In that case, the separate 
computer system would have a terminal co-locaced with each workstation 
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to be tested to provide each tester with access to the Scripts 
Information System. 

The SIR System described above may be utilized in conjunction with 
the present invention for the generation, tracking and resolution of 
5 errors, both in the application program being tested and in the scripts 
themselves. Preferably such a system would interface directly with the 
system of the invention. A tester would then be able to record problems 
encountered during a test without leaving SIS . The record of the 
problem is referred to as an SIR (System Incident Report) . 

10 Human interaction with, and control of, the script system sub- 

systems (YSCR, YSCA, YTRK, and YTRA) is primarily accomplished through a 
menu driven interface at a terminal. Within the menus the user 
interacts and controls the system by the use of either function keys 
(PFkeys) or the entry of a function code from each screen in the system. 

15 The function code is a two character field that is used to key a table 
to control SIS processing. Function codes are defined in a function 
control table 117. 

The Script Maintenance and Creation Sub-system { "YSCR" ) is used to 
create and maintain all scripts. This sub-system enables the user to 

20 enter all relevant script information, including workstation routing 
information, script narrative, a recap of the script, tester 
instructions, and all data required for testing. In addition to the 
entry of information, this sub-system provides the next available script 
number and also offers reporting and copy/delete features. 

25 The Script Administration Sub-system (°YSCA G > is used to maintain 

a large database of scripts. This sub-system enables a Script 
Administrator (a person responsible for managing SIS) to edit, copy or 
delete groups oC scripts according to a selection criteria (for example, 
status, blocking indicator, or categories) . An informational recap of 

30 the selected scripts is provided to aid in the script identification. 
Thus, the Script Administrator is able to perform mass copy and delete 
functions; and mass updates of status, blocking indicators and 
categories. In addition, YSCA allows the Script Administrator to 
generate script, recap and category reports. 
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The Script Tracking sub-system ( " YTRK " ) facilitates remote 
testing. YTRK is arranged around the functionality of -checking-out- and 
'checking-in - scripts. This procedure is similar to the way books are 
checked-out (borrowed) and checked-in (returned) from a library. A 
5 script is checked-out for use by a workstation and then checked back in 
to indicate completion of use of the script by the workstation tester. 
The system then forwards the script to the next workstation. The system 
also assigns tracking status codes to the individual scripts to aid the 
testers in script processing. 
10 The Script Tracking Administration sub-system ( m YTRh m ) of this 

system was designed to perform four functions-. Test Creation, Test 
Management, Test Progress Reporting, and Test Archival. All areas focus 
on the control of testing. Each of these functions is discussed below. 
The Test Administrator is the person responsible for managing a 
15 test. It is therefore his responsibility to setup the test and define it 
to the system. The Test Administrator defines the test name and 
identifies all the scripts which are to be processed through sub-system 
YTRA. This is test creation. 

The Test Administrator can also define a priority for a script. 
20 The priority of a script is displayed at the terminal to aid the tester 
in selecting which script to process. 

Management of the test process (Test Management) is the foremost 
function of YTRA. This function includes monitoring and controlling 
workflow. Monitoring includes identifying bottlenecks and problem 
25 workstations so that relief can be administered to expedite testing. 

Controlling workflow involves keeping scripts flowing through to 
the workstations. Once a script has completed all workstations, the 
Test Administrator may re-issue that script (that is, return the script 
to routing in the workflow) for the next test run. Controlling workflow 
30 also includes restarting or reinstating a script back into the workflow 
after resolution of a problem. 

The Test Administrator has several reports available for use 
during the test. The reports have been designed to automatically 
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provide tesc daca to the Administrator to facilitate decision making and 
test control . 

The archival function of YTRA deletes a test from the script 
tracking system (YTRK) . When a test is deleted, system reports are 
5 normally printed to archive the files. 

FIG . 2 shows the relationships between YSCR, YSCA, YTRK, and YTRA. 
YSCR and YSCA are both concerned with the creation and maintenance of 
scripts represented generally as block 204. Any authorized system user 
can create a script. With proper authorization, users can also modify 
10 existing scripts. Typically, only the Script Administrator can use the 
functions available in YSCA. 

YTRA is used to create tests, manage tests, report test progress 
and create archives of test results all utilizing the scripts created by 
YSCR . The functions available in YTRA would ordinarily be used only by 
15 a Test Administrator represented generally by icon 206. 

Sub-system YTRK routes individual scripts to the proper 
workstations in the proper order during a test run. The workstations 
used during a test are represented generically by the icons labeled 208, 
210, 212, and 214. If a tester detects an error in a script or in the 
20 test results, YTRK allows the tester to record and report the error to 
the Test Administrator. In the preferred embodiment, the error is 
recorded and reported using an SIR System (represented by icon 216) 
described above. A tester may also indicate that a script should be put 
on hold if the error is of a nature that continued routing of the script 
25 is either not desirable or not possible. 

FIG. 3 is a flow diagram for a preferred embodiment of the system 
of the present invention. FIG . 3 depicts the general flow of the 
system. 

Using the YSCR sub-system, scripts can be created by a user or 
30 tester as indicated by the icon labeled 302. YSCA permits the Script 
Administrator to set the script scatus (for example, new, active, 
closed, hold), blocking indicator (limiting the access to a script) and 
category. The Script Administrator can also perform the functions of 
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copying and deleting multiple scripts through the YSCA sub-system. 
These administrative functions are represented by the icon labeled 304. 

The YTRA sub-system provides a Test Administrator with a means for 
identifying the scripts for a specific test, initiating a testing 
5 process, monitoring the progress of the test, and resolving errors 
related to the scripts. Those functions are represented by the icon 
labeled 306. Access to YTRA is preferably restricted to the 
individual (s) playing the role of 'Test Administrator - . 

The YTRK sub-system facilitates the remote testing process. YTRK 

10 automates and controls the testing procedure and is used to record all 
required information (for example, information entered by a tester at a 
workstation). The functions performed within YTRK are represented by 
the icons labeled 308, 310, 312, 314, 316, 320, and 322. The normal 
testing procedure includes: selecting (steps 308,310) a script for 

15 routing; executing (step 312} the test at the routed workstation; 
recording (steps 314,316,320} any errors and/or test results; and 
passing (step 322) the script on to a next workstation at the completion 
of the test at the current workstation. 

Selecting the script for testing requires a tester at a 

20 workstation to first view (step 308) the list of scripts available for 
testing at his workstation and then select (step 310) one of the listed 
scripts. Running or executing (step 312) the test requires the tester 
to follow the instructions provided in the script. 

Recording the test results and/or any errors includes three steps. 

25 First, the tester must determine if any errors (either in the script 
itself or in the computer system being tested) have occurred during 
execution of the script. If an error is detected in the computer system, 
the tester records the error in the tracking system (YTRK) . In a 
preferred embodiment, YTRK will automatically invoke SIR System 316 for 

30 this purpose. If there is an error in the script data, or other 

problem, the tester can send che script to the test administration. If 
no errors are detected during the execution of the script or if an error 
is found but the script can continue the routing, the tester records 
(step 320) script test result (for example, document numbers for an 
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invoice, an error number, reason for hold) and any other information 
requested in the script. 

After the information has been encered the script is -checked-in" 
by the tester. YTRK Chen passes (step 322) the script to the next 
5 workstation in the routing order. The user is then free to view (step 
308) the list of scripts waiting to be executed at his workstation, 
select (step 310) a next script from that list, and then execute (step 
312) the selected script. 

b. For mer of a Script 

10 As set forth above, the basic elements of a script include routing 

information, tester instructions, and any necessary testing data. Other 
data may be included in a script as required for a particular testing 
application. For example, a script used to test the SAP system contains 
many sections of data. These sections are discussed below to provide an 

15 example of a script format. 

- ROUTING/ PROCEDURES 

Each script has a predetermined script routing. The route is the 
consecutive list of workstations a script must pass through in order for 
it to be fully executed. When a script is created, procedures (step by 
20 step instructions), are entered for each workstation. The system builds 
the routing based on the procedures entered. As a workstation completes 
the script the route list is -checked off. This provides a script 
tracking mechanism as well as a script workflow path. 

- NARRATIVE 

25 This section describes the functionality of computer system which 

is to be tested by the script and the expected results in a narrative 
format. It is a guide to help the testers understand the test case and 
the expected results. 

- ORDER HEADER 

30 This section contains all order header information necessary for 

entering a customer product order (that is, order entry). 

- ORDER ITEM 

This section contains all item (product) related information 
necessary for order entry. 
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- ORDER ENTRY DOCUMENTS 

This section provides a place Co document an order number assigned 
by the SAP system and any other document numbers produced during order 
posting . 

5 - ORDER MANAGEMENT DOCUMENTS 

This section provides a place to document the system assigned document 
numbers during the process of product distribution (for example, 
delivery note number, shipment number, goods issue number, and other 
document numbers) . 

10 - ORDER MANAGEMENT DIFFERENCES 

This section contains predetermined information such as quantity, batch, 
bin and any differences therebetween. An example would be a quantity 
difference between the product picked for shipment and the product 
ordered . 

15 - INVOICES 

This section provides a place to document SAP system assigned invoice 
work sheet and invoice numbers . 

- PURCHASE ORDER 

This section contains information relative to the entry of a purchase 
20 order as well as a place for document number recording. 

- PRODUCTION ORDER 

This section contains information relative to the entry of a production 
order as well as a place for document number recording. 

- RECEIPTS, ISSUES, TRANSFERS 

25 This section contains information relative to inventory movement sub- 
systems and a place for document number recording. 

- PREP . DATA 

This section contains information relative to preparatory data necessary 
to execute the script with a place for document number recording. 
30 - PROPERTY 

This section contains all the information necessary to record a fixed 
asset item. 

- CASH MOVEMENTS 
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This section contains all the information necessary to record a cash 
movement for credit purposes. 

- INVOICES (FAS - Financial Accounting System) 

This section contains the invoice header information and invoicing 
5 information relating to each item/product on the order. 

- VENDER INVOICE 

This section contains all payable related data for vendor invoices. 

- PURCHASE ORDER (FAS) 

This section contains the purchase order header information and 
10 financial information relating to each item/product. 

- FINANCIAL DOCUMENT 

This section contains header information relative to the creation of 
financial documents. 

- FINANCIAL DETAIL ITEM 

15 This section contains information relative to items within the financial 
document . 

- COST ACCOUNTING 

This section contains cost accounting data. 

- INTERNAL ORDER 

20 This section contains information relating to internal orders. 

- DIRECT COST & REVENUE PLAN 

This section contains information relating to a Direct Cost and Revenue 
Plan for an item within the internal order. 

- ACTIVITY USAGE & RESOURCE PLAN 

25 This section contains information relating to an Activity Usage & 
Resource Plan for an item within the internal order. 

- PRINT SEQUENCE 

This section stores the information that directs the order in which the 
sections of the script are printed. The print sequence standardizes the 
30 format of the printed script to facilitate their use by testers. 

- MISCELLANEOUS 

This section contains special information that is not part of any other 
defined section. 
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— The Databases and Tables 
In the preferred embodiment, the databases and tables are 
customized for the testing of the SAP system. However, the script 
system was developed to be flexible in adding, removing and adjusting 
5 the script structure to meet future and varying testing requirements. 

This can be done with limited programming effort (see script information 
control table 109) . 

The databases and tables, customized to the testing of the SAP 
system, are now described below as an example. As illustrated in Figure 
10 1, all four components of the SIS are integrated and use script 

information that is stored in an SAP database 110 in database files 112, 
114, and 116. The purpose and structure of the three database files 
112,114,116 are detailed below. 

15 1, Script Header File 11? 

The Script Header File 112 stores all descriptive information 
pertaining to a script. Every script will have a header record. Each 
header record contains the following sections. 

Script Identification {KEY): This identifies the script and 

20 script-set. There are four types of scripts: 1) standard, 2) Dependent, 
3) Multi-part, and 4) Dependent /Mult i -part . Standard scripts stand 
alone and are not related to nor dependent on any other script. 
Dependent scripts are used where one script is dependent on the complete 
execution of another script. Multi-part scripts are defined where 

25 multiple sets of information are required to define the complete 

business scenario. Dependent /Multi -part scripts are a combination of 
dependent and multi-part where a dependent script has multiple sets of 
information. 
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The format of che scripc ID identifies what type of scripc is 
created and must pass a series of validation rules. 1) The first four 
positions are required and must be numeric. They identify the ID of the 
script set. 2) The fifth position, if entered, must be alphabetic or a 
5 dash. If this position is alphabetic, it identifies the script as 
dependent and defines the order of dependency. If it is a dash, the 
script is a multi-part. If it is blank, then the script is standard. 
3) The sixth position, if entered, must be numeric (1-9) and can only be 
entered if the fifth position is non-blank. Also, if the fifth position 

10 is a dash, the sixth position is required. If the fifth position is 
alphabetic and the sixth position is filled in, then the script is a 
dependent/multi-part. 4) It is not valid to mix types of scripts within 
a script set. For example, if script 3001 already exists, then script 
3001A (a multi-part script) cannot be created and visa-versa. 

15 The Script ID is "smart* in the sense that all four system 

components evaluate the format of the ID to drive their respective 
processing. Such processing is outlined where necessary. 

Creation Date: The date when the script was originally entered in 
the system. 

20 Owner: The user-id of the person who is responsible for the script 

information. Usually, it is the person who actually entered the script 
in to the system. 

Date of Last Update; The date when the last update was applied to 
the script information. 
25 Owner of last Update: The user-id of the person who applied the 

last update to the script information. 

Current Section: The identifier of the sections currently defined 
for the script . 

Narrative Number: The text narrative number assigned to this 
30 script. The narrative number is derived from the script ID. Refer to 
the section describing the script narrative for more information abouc 
the derivation of the script narrative number. 
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Recap: A brief overview of the script's functionality and purpose. 

Notes: Special information pertaining to a script that is not 
related to the functional aspects of the script. 

Status: The current state of the script; for example "new, 
5 "active" , "canceled", or other preselected state descriptions. The 
valid status codes are defined in script and test status definition 
table 105, discussed below. 

Blocking Indicator: This field, when set ON, prevents updates from 
being applied to the script. Usually the blocking indicator is set ON 
10 when the script is being tested. 

Print Sequence: Defines the sections and order of presentation 
when the script is printed. The print sequence identifies which 
sections are printed by their corresponding section code. 

Current Default Print Sequence: The print sequence that is used 
15 unless a specific print sequence is entered for that script. 

Categories: A script category is a means for grouping similar 
scripts. Scripts may be grouped by functionality, area, or test (to name 
a few) . A script may have a maximum of twenty- five categories assigned. 
The valid category codes are defined in a script category definitions 
20 table 107, discussed below. 

Order Item Count: The current number of order items defined for a 
script . 

2^ scripc. section File 114 

The Script Section File 114 stores all data relating to the 
25 functional aspects of the business scenario. Each record on the file 
contains data relating to a single script section. A script may not 
have associated section information. Each record contains the following 
sections : 

Script Identification (KEY): See script header file 112 discussed 

3 0 above. 

Section Identification (KEY) : Each script section has an 
associated identification code which is used to separate and store the 
information on the system. 
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Sequence Number (KEY) : Some script sections may have multiple 
occurrences, for example a script may have many order items. This field 
allows for multiple records of information within a given section. 

Section Information: This is a free-format area for the storage of 
5 the section information. The information stored in this file is 

controlled by a script information control table 109, discussed below. 

3. Script Proc edures File 116 

The Script Procedure File 116 stores all data relating to the 
10 procedures required to execute the script. Each record on the file 

contains data relating to a set of procedures associated with a specific 
workstation. Each record contains the following sections. 

Script Identification (KEY): See script header file 112 discussed 

above . 

15 Workstation Identification (KEY): Identifies the workstation Cor 

which the set of procedures are defined. Workstations are defined in a 
workstation definitions table 103, discussed below. Only workstations 
that are defined in the procedures may have workstations defined in the 
routing . 

20 Workstation Routing Sequence (KEY): Identities the specific 

routing sequence for the specified workstation. This is required 
because a script may return to a workstation more than once and a set of 
procedures applies to a specific workstation performing a specific set 
of tasks. 

25 Sequence Number (KEY) : A set of procedures may have more than one 

"page" of information. This field allows a user to define multiple 

•pages' of procedures for a specific workstation. 

Procedure Information: This is a free-format area for the storage 

of the procedure information. 
30 There are also several SAP tables which support all of the 

activities of the script system components. They are outlined below. 
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A- Script Information Control Table 109 

Defines the record format for every section ot the script 
information. The table specifies the fields and their corresponding 
length and displacements within the data area of the Script Section 
5 Information File 114. The table contains the following information. 

Section Identification (KEY) : See the discussion on the script 
section file 114 set forth above. 

Subsection/Version ID (KEY) : This field has two purposes. First, 
it allows a section that has too many fields to be subdivided. An 
10 example of this is the order item section. It is divided into item 
information and pricing information. The information for both 
subsections is physically stored on a single record but is displayed to 
the user on two separate screens. The subsection ID allows each screen 
co be defined separately while still relating to one record of 
15 information. 

Second, when used as a version ID, this field is used when the 
information within a section needs to be reorganized. A section may be 
redefined using a different version ID. By executing the data 
reorganization facility developed for this system, the section 
20 information can be reformatted in the desired manner. 

Field Sequence (KEY) : Identifies the order of presentation and 
storage of the script section's information. (Presentation refers to 
the printing of information on the Script Print report). 

Field Type (KEY) : There are three types of fields that can be 
25 stored on a script section: 1) 'Entry - , 2) "Data-, and 3) -Object - . 

•Entry" fields are used to tell the reporting modules that a blank line 
is to be printed if the corresponding data field does not have a value. 
For every "entry" field, there must also be a data field. "Data' fields 
are the fields that store the script information. "Object" fields were 
30 developed in conjunction with the miscellaneous section (2) so that the 
user could enter the desired field description. 
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Object Name: Every piece of information defined Cor a section has 
some level of description. Many of these descriptions are store in 
SAP's Data Dictionary. The object name defined for a field corresponds 
co the Data Dictionary name. When the script information is printed, 
5 che data dictionary is read to retrieve the description of the field. 

Field Displacement: This indicates the location of the field from 
the beginning of the section information. 

Field Length: This indicates the length of the field. 

Mapping Sequence: This field is used during data reorganization of 
10 the script information. 

5 , <?rrinr_ Tra rkinn Information Table 111 
The script tracking information table ill stores each 
workstation's tracking record for every script included in a specified 
15 test. The table contains the following information. 

Test Identification (KEY) : Identifies a specific test. The Test 
Identification and run numbers are defined in a test identification 
definitions table 115. 

Run Number (KEY) : Identifies a specific run within a test. 
20 Script Identification (KEY): See script header file 112 discussed 

above . 

Iteration (KEY) : Identifies a specific iteration for a script 
within a run and test. 

Station Sequence (KEY) : Each script follows a pre-assigned route 
25 of workstations. Every "stop- on the route has an associated routing 
sequence number. The workstation sequence corresponds to the routing 
sequence on the script information. 

SIR Indicator - Script: This indicates whether the script has 
exposed an error in a previous workstation but was not severe enough to 
30 prevent the script from continuing through the test process. 

SIR Indicator - workstation: This indicates whether an error has 
been discovered at the current workstation. 
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Status: The status is a indicator which is used to track the 
progress of the testing process at a workstation. The valid status 
codes are defined in a script and test status definitions table 105. 

Tester ID: The user ID of the person testing the script at a 
5 given workstation. 

Arrival Date: The date the script arrived at the workstation. 

Arrival Time: The time the script arrived at the workstation. 

Start Date: The date the test process began for a script at the 
workstation . 

10 Start Time: The time the test process began for a script at the 

workstation. 

Exit Date: The date the test process was concluded for a script at 
a workstation. 

Exit Time: The time the test process was concluded for a script at 
15 a workstation. 

Testcenter: The geographical location of the tester. Test centers 
are defined in a test center definitions table 121. 

Reinstate Count: A count of the number of times this script was 
reinstated by the Test Administrator at this workstation. 
20 Priority Indicator: If the script is a priority script, this 

indicator is set so that che script is displayed at the top of the list 
for processing first. 

Document History Table 113 

25 A document history table 113 stores all of the information (for 

example, results) recorded by testers for a script during che course of 
a specified test. As a script is processed, the tester records various 
forms of information including documents such as order number, delivery 
note, shipment, invoice, and other information. This information is 
30 made available to subsequent workstations. The table contains the 
following sections. 

Test Identification (KEY) : (See table 111) 

Run Number (KEY) : (See table 111) 

Script Identification (KEY) : (See table 111) 
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Iteration (KEY): (See table 111} 

Document Sequence (KEY): This field is incremented each time a 
document is posted to the cable. It allows multiple documents to be 
entered at one workstation. 
5 Document Type: This field identifies the type of document being 

entered. The document type codes are defined in a document type code 
definition table 119. 

Document Number: As the tester executes the script and posts 
orders and other information, SAP returns document numbers to be 
10 recorded within Che script system. This field is used to store the 
information returned from SAP. 

Miscellaneous Information: This field is used to store any 
miscellaneous information concerning the document. 

workstation Identification: This field contains the ID of the 
15 workstation that is posting the document information. 

Tester Identification: This field contains the ID of the tester 
posting the document information. 

Document Date: This field contains the date on which the document 
was posted to the table. 
20 Document Time: This field contains the time when the document was 

posted to the table. 

Testcenter: (See table 111) 

Station Sequence: (See table 111) 

25 7. Workstation pp finitiong Table 1Q3 

This table defines all the valid workstations and their associated 
descriptions. The table contains the following entries. 

Language Indicator (KEY): This table is language dependent. 
Therefore, the workstation descriptions are displayed in the language 
30 that is standard for a region. 

Workstation Identification (KEY) : This entry is a 
code/abbreviation which represents a specific workstation. 

workstation Type: This entry indicates whether the workstation is 
a regular workstation or an SIR desk. 
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Description: This entry is a description of the workstation. 
Document Entry Required Indicator: This entry indicates whether 
documents must be entered at a workstation during the testing process. 
Priority Sequence: This field is used to order che workstation 
5 information on screens. 



Script and Test Status Definitions Tablfi IPS 

The script and test status definitions table 105 defines all of 
the possible script status and tracking status codes. Script status 
10 codes define the state of the script (new, active, held, canceled). 

Tracking status codes define the current state of a script at a given 
workstation (for example, in-progress, in-error) . Each status code has 
an associated description. The tracking status codes used by the system 
as listed below. 

15 General Statuses: S - Start script at initial workstation, B - 

Script in workstation's In-Basket, I - Script In-Progress at 
workstation, D - Documents entered, and C - Script complete at 
, workstation. 

Problem Statuses: X - SIR entered, documents pending workstation. 
20 Administrative Statuses: E - Error found, SIR recorded/script 

held; T - Error fixed, script restarted; H - Script held, sent to Test 
Administrator; R - Script removed from test; F - Script finished run; 
and P - Script run complete, DEPENDENT script started. 

Script and test status definitions table 105 contains the 
25 following entries. 

Language Indicator (KEY): This table is language dependent. 
Therefore, the status descriptions are displayed in the language that is 
standard for a region. 

Type Code (KEY) : A status code can be used to identify the state 
30 of a script or the state of testing for a script at a workstation. This 
code identifies which status codes apply to scripts and which apply to 
testing . 

Status Code (KEY) : A code representing a specific script or test 
status . 
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Description: The description of che status code. 
9 , tp^E Tdenti firar.ion Defini tions Ta b! e 115 
The test identification definitions table 115 stores the 
information regarding what tests are currently defined. 

Test Identification: As the Test Administrator initiates a test, 
defining the ID of the test is part of the process. The test ID is used 
to identify a specific test. Every tester who is involved in the test 
process is required to identify which test they are working with, since 
many tests may b«; in progress at the same time. 

Run Number: Each test may have many runs. This defines the runs 
that have been created for a specific test. 

10 Document H istory Information Table 119 
The document history information table 119 defines all the 
possible documents type codes that may be entered into the system. Each 
15 code has an associated description. 

Document Type Code: A two character ID corresponding to a specific 
document type. Documents types include order numbers, invoice numbers, 
shipment numbers, and other preselected types. 

Description: The description of the type of document. 
20 11. Testo i n t er De finitions Table 121 

The testcenter definitions table 121 defines the valid 
geographical tes : ; locations. 

Testcenter: A testcenter is a general location or area where the 
testing is taking place. One testcenter may be in the U.S. and another 
25 in Canada. This field provides a method of identifying all possible test 
centers . 

Description: The description of the testcenter 
1? , ficrin: Caq p?orv Definitions Table 107 

The script category definitions table 107 defines all of the valid 
category codes tnat may be assigned to a given script. Each category 
code has an associated description. 

Category Type: This field Identifies a particular method of 
grouping scripts together. A category type may be used to group scripts 
by functional purpose, area of responsibility, or test. 



30 
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Category Code: This field is a five digit code which is assigned 
to each category. 

Description: This field contains a description of the category 

code . 

5 

12. Function Control Table \u 

The function control table 117 defines the valid PFkey usage and 
associated function codes for each screen within the system. 

10 IX, SCRIPT MAINTENANCE AND CREATION SUB-SYSTEM fYSCRl 

^ Purpose 

The Script Maintenance and Creation ("YSCR') sub-system of SIS 
provides a means for creating, storing, retrieving, and updating the 
script information. YSCR is a menu based or menu-driven sub-system. 

15 Each menu allows the user to specify a script and direct the processing 
to the desired section or function. The sub-system may be used by 
anyone who is involved in the creation and testing of scripts. YSCR is 
used to create and maintain all scripts. 

The YSCR sub-system enables the user to enter all relevant script 

20 information, including routing information, script narrative, a recap of 
the script and all necessary data for testing. In addition to the entry 
of information, this sub-system proposes the next available script 
number and also offers reporting and copy/delete features. 

2 5 Sub-system Functions 

The script information is created and maintained through a series 
of menus preferably presented on a video display screen of a terminal. 
Each menu is responsible for a particular grouping of script sections. 
When a section screen is invoked, all fields and data previously entered 
30 are displayed (If the section does not exist, the fields are displayed 
with no data) . The user has the option to invoke another section or 
add/update/delete the information for the current section. 
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Each section of the script is assigned a one digit section ID. 
script sections are referred to using this ID throughout some of the 
functions of the sub-system, such as copy, delete and print sequence. 
The function code is the section identifier preceded by an m S m . Script 
5 sections and functions can be accessed using the function code, or a 

PFkey. The administrative section has a section ID of -V . There is no 
function code or PFkey, as this section cannot be accessed through sub- 
system YSCR. 

As shown in FIG. 4, when a user at a terminal invokes YSCR 102, 
10 the main menu 404 is presented on the screen. Main menu 404 presents 
the user with a list of the PFkeys and Function codes to access all of 
the areas of a script as indicated in FIG . 4. Each of the areas is 
presented as a irenu which permits the user to select the script section 
of interest. From main menu 404, the user may select any of the utility 
15 functions 406 or script basic sections 408. The user may also select an 
Order Life Cycle (OLC) menu 410, a Plant Information Management (PIM) 
menu 412, or a Financial Accounting System (FAS) menu 414. Each of the 
available selections is discussed below. 

20 Fi^qir Sections 408 

The basic sections 408 of a script can be accessed and information 
can be entered in those sections from main menu 404 through the use of 
PFkeys or function codes. Each of the basic sections of the script, 
shown in FIG. 5, can be displayed on the screen of a terminal. These 

25 include narrative 502 (which includes Scenario 503 and Expected Results 
505), routing/procedures 504, miscellaneous 506. and print sequence 508. 
In this manner scripts can be created, reviewed, or modified. 

The narrative section 502 is a text section, and therefore, SIS 
uses the text processing capabilities of SAP to edit it. 

30 
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Z, — order Life Cycle CQLC) Sections Menu 410 
Within Che OLC menu 410 the user may review, create or modify any 
of the OLC sections of a script. The OLC menu 410 presents the user 
with a list of the PFkeys and Function codes to access all of the OLC 
5 sections as indicated in FIG. 6. Each of the OLC sections is presented 
as a screen or series of screens formatted to guide the user through the 
entering of data. The utilities 406 and the basic sections 408 can be 
accessed from the OLC menu 410. 

The script sections which can be accessed from OLC menu 410 
10 include an order header section 602, an order item section(s) 604, an 

order management section 608, an OE (order entry) documents section 606, 
an OM (order management) differences section 610 and an invoices section 
612. From order item section 604, an item pricing function 614, an item 
copy function 616 and an item delete function 618 may be accessed. 
15 Block 620 indicates functions which may be executed from order 

item section 604. Functions indicated in a block (for example, block 
620), will not cause a new screen to be displayed. Similarly, block 622 
indicates functions which may be executed from item pricing section 614. 

20 i- Plant: Information Management ("PIMM Se ctions Menu 41? 

Within the PIM menu 412 the user may review, create or modify any 
of the PIM sections of a script. The PIM menu 412 presents the user 
with a list of the PFkeys and Function codes to access all of the PIM 
sections as indicated in FIC. 7. Each of the PIM sections is presented 

25 as a screen formatted to guide a user through the entering of data. The 
utilities 406 and the basic sections 408 can also be accessed from the 
PIM menu 412. 

The sections which may be accessed from PIM menu 412 include a 
purchase order section 702, a receipts, issues and transfers section 
30 704, and a production order section 706 and a preparatory data section 
708. Block 710 indicates functions which may be accessed from 
preparatory data section 708. 
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^ Financial Accounting Syst em f'FA^ * 1 Sections Menu 414 

Within the FAS menu 414 the user may review, create or modify any 
of the FAS sections of a script. The FAS menu 414 presents the user 
with a list of the PFkeys and Function codes to access all of the FAS 
sections as indicated in FIG . 8. Each of the FAS sections is presented 
as a screen formatted to guide the user through the entering of data. 
The utilities 406 and the basic sections 408 can also be accessed from 
the FAS menu 414. 

The sections which may be accessed from the FAS menu 414 include a 
financial document section 803, a financial detail item section 807 , a 
property section 802, an invoice (FAS) section 804, a cash movements 
section 806, a vendor invoice section 808, a purchase order (FAS) 
section 810, a receipts, issues and transfers section 812, an internal 
order section 804, and a cost accounting section 814. A direct cost and 
15 revenue plan section 809 and an activity usage and resource plan section 
811 may be accessed from the internal order section 80S. Further, 
blocks 816, 818, and 820 indicate the functions which can be accessed 
from section 804, 808, and 810, respectively. 



10 



20 Utilities 4Q6 

Listed below are the utilities 406 available in YSCR to enable a 
user to perform functions associated with creating and maintaining 
scripts. The organization and relationships of the utilities is shown 
in FIG . 9. All of these functions can be accessed from the main menu 

25 404 and from each of the group menus 410, 412, and 414. A brief 
description of each utility or function is provided below. 

Propose Script Number 902: This utility searches the script 
database 110 (from a user-specified point) and returns the next 
available script identification. 

30 Copy Script 906: This utility copies the specified contents of a 

script to a new script identification. The script may be copied in par 
or in full. Block 928 indicates a function which may be entered from 
copy script 906. 
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Delete Scripc 908: Deletes Che specified concents of a script. 
The scripc may be deleCed in full or only partially. 

Rename Script 910: Renames all associated components of a script 
to the specified script identification. Block 930 indicates a function 
5 which may be entered from rename script 910 which will not result in 
display of a new screen. 

Print Script 912: Invokes routines to print the contents of the 
script in a formatted list. 

Selective Browse 904: This utility searches the current script 
10 information and returns a list of scripts 914 that meet a user-specified 
set of criteria. (For example: A user may need to view all scripts that 
have been created with a company code equal to '02'.) The Selective 
Browse function enables the user to view a list 914 of scripts that 
match the selected criteria. 
15 Block 92 6 indicates functions which may be entered from selective 

browse 904 which will not result in display of a new screen. 

List 914 displays the script number, sections included in the 
script, and a recap of the narrative. From this list, the user can 
enter utilities 406, basic sections 408, or a report menu 916. In 
20 addition, the user may re-enter the menu (indicated by menu sections 
icon 915) from which the browse utility was invoked. A block 924 
indicates functions which can be accessed from script list 914 which 
will not result in display of a new screen. 

Report menu 916 allows generation of a script recap report 918 or 
25 a script category report 920, or printing of individual scripts print 
reports 912 via script print parameters function 922. 
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The script Recap Report 918 prints a list of all the scripts in 
the given range that match the selection criteria entered. The list 
includes the script number, the script status and the recap information. 
The Script Category Report 920 lists the script number, the script recap 
5 and the category codes assigned to each script. Both of these reports 
can be selected from report menu 916. These reports produce a hard-copy 
version of the script information for a list of selected scripts. Only 
those scripts that have been 'marked' in the script list are passed and 
printed on this report. Each system has its own version of the Script 
10 Print Report. 

e. script Database Access /Upd a t e 

The Data Ilntry System has many screens that process script section 
information. All reading and updating of information has been developed 
15 in a common routine to facilitate adding and removing script sections 
and information. 

TTT. ECRTPT A.PMTNT STRATTON SUB-SYSTEM (YSCA) 

a, Purposis 

20 The Script. Administration Sub-system (YSCA) 104 provides a means 

for applying mas:s updates to the scripts. The functions provided by 
YSCA are depicted in FIG. 10. YSCA 104 is used to manage/maintain a 
large number of scripts. YSCA 104 enables a Script Administrator to 
maintain individual or a range of scripts by status, blocking indicator 

25 and categories. An informational recap of the selected scripts along 
with reporting functions are provided to aid in the identification of 
scripts. In addition, the sub-system provides mass copy and delete 
functions and mass updates of status, blocking indicators and 
categories. Du<; to the critical nature of this sub-system, access is 

30 limited to the individual (s ) playing the role of "Script Administrator". 

In genera] the Script Administrator uses YSCA 104 to control and 
regulate access, modifications and release of scripts. Referring to 
FIG. 11. an example of the operation of YSCA 104 in reviewing and 
releasing a new script 1102 is provided. 
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A new or modified script 1102 is submitted by a tester for review 
by the script Administrator at a step 1104. The Script Administrator 
determines if the script is acceptable (that is, in condition to be 
released for use in testing) at a step 1106. If the script is 
5 acceptable, the Test Administrator updates any categories for that 

script that need to be updated at a step 1108, changes the status of the 
script to active at a step 1110 so that the script can be used in a 
test, and ensures that blocking is on for the script at a step 1112 so 
that it cannot be further modified. Block 1114 indicates that the task 
10 of the Test Administrator are then completed with respect to the new 
script 1102. 

If the script is found to be unacceptable at step 1106, then the 
status of the script is set to hold at a step 1116. At step 1118, the 
script is returned to the tester who created or modified it so that it 
15 can be corrected. 

ha Sub-svstem Functions 

JL Overview 

Each of the functions provided by YSCA 104 are invoked from a 
20 script list 1004 presented to the user as shown in FIG. 10. After 

invoking YSCA 104, the user is presented with a script selection screen 
1002. The user may define the criteria for a collection of scripts (the 
script list) by making the appropriate selections in the script 
selection screen 1002. The script list 1004 is defined by the use of 
25 selection criteria including script number range, status, blocking 
indicator, category codes, script section, script owner, recap text, 
person who last updated script and date of last update. 

Block 1030 indicates functions which may be executed from script 
selection screen 1002, which will not result in the display of a new 
30 screen. 
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Afcer the user has selected the criteria for the script list, the 
script list 1004 is generated by activating the appropriate PFkey or 
entering the Function code and displayed for the user. While the script 
list 1004 is displayed, the user can block, unblock, mark, and un-mark 
all or selected >nes of the listed scripts. All of the functions below 
are performed only for the scripts that have been selected. Each of the 
functions descrised below is accessed from the script list 1004 through 
the use of the appropriate PFkey or Function code. 

Mass Copy 1006: The mass copy function creates a duplicate set of 
selected scripts starting at a specified script number. The scripts can 
be copied with or without the categories. There are two types of copy 
functions available. A -direct • copy copies the selected scripts to 
the specified range and overlays any current scripts within the range. 
A -relative' copy copies the selected scripts but bypasses any current 
15 scripts within the range and finds the next available script number. 

The Test Administrator has the option to perform, cancel or simulate the 
copy. The sub-system then produces a report 1008 detailing the results. 

Mass Delete 1010: This function deletes a selected set of scripts 
(including all related script information and narratives) . The user has 
20 the option to perform the delete, cancel the delete or simulate the 
delete. The sub-system produces a report 1012 detailing the results. 

Mass Category Update 1016: This function either adds or removes a 
specified category code to a selected set of scripts. The sub-system 
then produces a report 1018 listing the results of the update. 
25 Mass Status Update 1014: This function changes the script status 

of a selected set of scripts to a specified value. 

Administrative Section Update 1020: This function provides a means 
tor the script Administrator to update the status, blocking indicator, 
and category information for a selected script. 

Report Menu 1022: This menu is used to invoke routines to print 
the current concents of the script information in the following 
formatted reports. 
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- Scripc Print Report 1025: This report includes the contents of the 
script in a formatted report as selected by script print parameters 
function 1024. From function 1024, the administrator can enter a test 
identification and run number to print on the scripts so the testers can 

5 see on the script report in which tests the script will be executed. 

- Script Recap Report 1026: This report produces a list of selected 
scripts along with their recap information and status code. 

- Script Category Report 1028: This report produces a list of selected 
scripts along with their recap information and category codes. 

10 Block 1032 indicates the other functions which may be performed 

from script list 1004. These other functions will not result in the 
display of a new screen (that is, menu). 

Status, Blocking and Categories 

15 When a script is created, the administrative section (Section Y) 

is automatically assigned. The sub-system assigns a status of N(ew) , 
and a blocking indicator of N(o) to all newly created scripts. 
Categories are assigned by the Script Administrator. 

The status indicator is represented as one of the following: N - 

20 New, A - Active, C - Canceled, H - Hold. This indicator is used to 
indicate which scripts are: active and ready to be tested; new and 
still in development; closed or canceled and will not be tested; or on 
hold, and will be tested at a later date. 

Generally, when the status of a script is changed to active, the 

25 script will also be blocked. The active status represents that the data 
on the script is completed, and the script is ready for use. Therefore, 
the script in most cases is blocked to prevent alterations of data. The 
Script Administrator always has the capability to unblock and modify a 
script . 
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The blocking indicator is either Y(es) or N(o) indicating whether 
or not the script is blocked. When a script is blocked, the data cannot 
be altered. However, each section of the script can be viewed just as an 
unblocked script. Also, the script can be printed or copied. It cannot 
S be deleted. If a blocked script is copied, the new script is not 
blocked and the original script remains blocked. 

Categories should be set at the time the script is created. This 
enables the Script Administrator to easily identify the scripts by 
group. For example, a U.S. Area script has a category code of *USAR* 
10 and should be assigned that code at creation. When the Script 

Administrator wdnts to view all U.S. Area scripts, he would select the 
category "USAR" and the sub-system would display only those scripts. 

When the script status is changed to active, the script should be 
reviewed and other category codes applied where needed. For example, if 
15 the script is an order life cycle script that is being tested in a 

particular test, categories corresponding to the test and to the type of 
script C0LCYC): should be assigned to the script. 

i, Mags Upda rp Functions 

20 The Script Administrator can copy a range of scripts, to another 

range. The copy features can be relative or direct. A direct copy 
replaces any scripts currently existing in the range selected to be 
copied to. A relative copy skips a number in a range if a script 
already exists in the selected range. 

25 The mass delete function allows the Script Administrator to select 

a range of scripts and delete the entire script. Both the mass delete 
and the mass copy provide a report when the function is completed. In 
addition, both the mass delete and mass copy features allow the Script 
Administrator tc run a simulation before processing actually occurs. If 

30 the simulation is run, a report is generated displaying the script 

changes that will occur when the function is actually performed. No 
changes are made to current scripts during the simulation. 
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Mass status, blocking and categorization enable the script 
Administrator to select a range of scripts and change the status or 
blocking on all the selected scripts. Additionally, categories can be 
added or deleted for the selected range of scripts. 

4, .Reports 



The Administrative Reporting function enables the Script 
Administrator to view a list of scripts that match the selected 
criteria. The list displays the script number, status and blocking 

10 indicators and a recap of the narrative. From this list, in addition to 
blocking, status and category updates, the sub-system provides flexible 
reporting capabilities. 

In addition to printing the individual scripts, there are two 
types of reports that can be generated. The Script List Report prints a 

15 list of all the scripts in the given range that match the selection 

criteria entered. The list includes the script number, the status and 
the recap information. The Script Category List Report lists the script 
number, the script recap and the category codes assigned to each script. 

20 JUL SCRIPT TRACKING ADMINISTRATION SUB-SYSTEM t YTRA 1 

a. Purpose 

The script tracking administration (YTRA) sub-system 108 provides 
the Test Administrator with a means for initiating a testing process, 
identifying the scripts for a specific test, monitoring the progress of 
25 the test, and resolving errors related to the scripts. Access to the 

script tracking administration sub-system is restricted to individual (s) 
designated as "Test Administrator.* 

b. Sub-system functions 

The script tracking administration sub-system (YTRA) 108 provides 
30 administrative functionality to the script tracking sub-system (YTRK) 
106. FIG. 12 is a high-level functional diagram of the script tracking 
administration sub-system 108. The cunct ional ity is illustrated in 
terms of access screens and system reports. A script section/test 
selection screen 1202 provides access to the following functions. 
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Reassign 3203: The Test Administrator has the power to -reassign* 
scripts that arcs currently assigned to a particular workstation. The 
reassign function changes the workstation which is responsible for a 
script. This prevents a set of scripts from being delayed due to a 
5 tester's absence:. 

Create Tes:t 1206: This function defines a set of scripts to be 
tested. It prepares the necessary tracking information at the initial 
workstation for each script. Once this function has been completed, the 
test process may begin. 

10 Delete Test 1208: Deletes all the associated tracking information 

for a specified test. The delete test function is normally used to 
■clean up' obsolete information from previous tests. It is also used to 
delete individual scripts that were added to a test in error. 

Monitor Test or script list 1204: This function displays a list of 

15 scripts that require the attention of the Test Administrator. These 

include scripts that have been found to be in error or have been held by 
a tester; and scripts that have completed the testing cycle and may 
require the nexu run to be initiated. 

The Test Administrator has three options for scripts that are in 

20 error: restart the script at a specified point in the routing sequence, 
reinstate the script at the point where the error was found, or remove 
the script from the test. Restarting a script indicates that the error 
was of such a nature that some processing needs to be redone. A new 
iteration is created. 

25 Reinstating a script indicates that either the error was not 

critical enough to halt the testing process and the process can continue 
where it left o:!f. A new iteration is not created. Removing a script 
indicates that i:he error was severe enough that the script cannot be 
executed in the test. 

30 System Reports 1210: Allows the Test Administrator to monitor the 

progress of the test by reviewing various reports. According to the 
present invention, the following reports are defined. 
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- Creace Test: This report is executed when the Create Test function is 
invoked. It produces a list of scripts to be added to the specified 
test based on specified search criteria. 

- Delete Test: This report is executed when the Delete Test function is 
5 invoked. It produces an audit trail of all records deleted during the 

process . 

- Script History/Forecast Report 1212: This report produces a 
history/forecast report for a script. The history portion outlines 
where the script has been in the testing process. The forecast portion 

10 indicates where the script still has to go. 

- Test Statistics Report 1214: This report produces a statistical 
analysis of the specified test. It provides the user with various 
levels of information, including test and run statistics and workstation 
analysis. The statistics are computed based on scripts and script sets. 

15 - SIR History Report 1222: This report produces a history of SIR'S 

reported for a specified test. Information on the report includes the 
number, person responsible, the status of the SIR, date opened/closed 
and what scripts are affected. This report also shows statistics on 
scripts that have been restated, reinstated and removed. 

20 - Test and SIR Statistics Report 1216: This report produces a 

statistical analysis of the specified test. It provides the user with 
various levels of information including test and run statistics and 
workstation analysis. These statistics are computed based on 
workstations per script. This report also shows how many SIR's were 

2 5 opened and closed for the day and the period which is covered by the 
report . 

- Tester statistics Report 1218: This report produces a list of testers 
associated with a test. It provides an analysis of the workload for 
each tester. 

30 - Document History Report: Described in the description of the 
tracking sub-system. 
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Referring again co FIG. 12, Che functionality of the script 
tracking adminisiirat ion sub-system 108 will be described. When a Test 
Administrator invokes the script tracking administration sub-system 108, 
a 'script select:;on/test selection - screen 1202 is presented. 
5 At the script selection/test selection screen 1202, the Test 

Administrator is given the option to select which tests are to be run, 
and which script;; are to be used in running those tests. The Test 
Administrator can also add a priority flag to certain scripts in a test. 
Additionally, thu Test Administrator may choose to generate reports 

10 detailing the status of the present or past tests. 

After the i:est is created, a report is displayed showing which 
workstation each script is at and verifying the creation of the script 
in the test. If a script could not be created, then the sub-system will 
display a message giving the reason why the script was not created. For 

15 example, a dependent script will not be added to the test until the 

script upon which it depends has been tested. The sub-system will add 
subsequent parts of dependent scripts automatically. 

Once the scripts have been selected from the script selection/test 
selection screen 1202, the test can be created and the test process may 

2 0 beg i n . 

If the Test: Administrator chooses to monitor a test, a script list 
1204 is presented. At this point, the Test Administrator is given 
access to a list of scripts that have either completed a run or require 
some action. Through the use of function codes or PP keys, the Test 
Administrator can choose to reinstate a script, restart a script, remove 
a script from tha test list, refresh the script list, initiate a new run 
for an individual script, or scroll through the script list. 

The Test Administrator may choose to generate a create test report 
1206 detailing trie list of scripts selected for that particular test. 
Create test report 1206 can also be generated from script selection/test 
selection screen 1202. 



25 
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If the Test Administrator deletes a test from script 
selection/test selection screen 1202 via the delete test function, the a 
delete test report 1208 is generated. This produces an audit trail of 
all records deleted during the test processes. 
5 From script selection/test selection screen 1202 the Test 

Administrator may choose to generate various system reports. If such a 
selection is made, the Test Administrator is presented with a report 
menu screen 1210. From report menu screen 1210 numerous system reports 
may be generated. The Test Administrator may choose to generate a 
10 script history/ forecast report 1212. This report produces a history and 
forecast report for a script. The history portion of this report 
outlines where the script has been in a testing process. The forecast 
portion of this report indicates to which locations the script will go 
from the current time through completion of the test. 
15 The Test Administrator may choose to generate a test statistics 

report 1214. This report produces a statistical analysis of the 
specified test, it provides various levels of information including 
test statistics, run statistics, and workstation analysis. 

The Test Administrator may choose to generate a tester statistics 
20 report 1218. This report produces a list of testers associated with the 
specified test and provides an analysis of the workload of each tester. 

If the Test Administrator wishes to generate an SIR history 
report, the Test Administrator makes the appropriate selection on report 
menu 1210 and is presented with an SIR information parameters function 
25 1220. From SIR information parameters function 1220 the Test 

Administrator can generate an SIR statistics report 1222. This report 
produces a statistical analysis of the number of SIR'S reported for a 
specified test. Information contained in this report includes the 
number of SIR'S, the status of each SIR, and which scripts were 
30 affected. 
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From script list 1204, the Tesc Administrator can also choose to 
restart a script or a scroll through document history and print an SIR 
information report. If che Test Administrator chooses to restart a 
script, a restart workstation screen 1224 is presented. At this screen, 
the Test Administrator can choose to restart a script at a specific 
workstation. If a restart is selected, the sub-system will displays a 
document entry screen 1225. The Test Administrator uses this screen to 
enter a message to the testers. 

If the Test Administrator chooses to view the document history of 
a script, he is presented with a document history screen 1226. From 
document history screen 1226, the Test Administrator can scroll through 
the various documents and choose to print an SIR information report 
1228 . 

Blocks 120^., 1207 , 1229 and 1227 indicate other functions which 
can be executed from script selection/test selection screen 1202, script 
list 1204, restart station function 1225, and document history function 
1226, respectively . 

As previously mentioned, the functions of the script tracking 
administration sub-system are invoked using SAP function keys (PF keys) 
or function codes. The specific function keys and function codes are 
shown in FIG. 12 . 



When invoking the script tracking administration sub-system (YTRA) 
to identify the scripts for a specific test, initiate a testing process, 
and monitor the progress of a test, a general methodology is followed by 
the Test Administrator. This methodology is described with reference to 
FIGS . 12 and 13. 

In a step 1302, the Test Administrator initiates the test process. 
This is done via a script selection/test selection screen 1202. Once 
the script is created, the test is executed. During execution, in a 
step 1304, the Test Administrator generates reports on the test status 
and statistics of. the test. These reports are generated from report menu 
1210. 
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In a step 1306, che Test Administrator monitors the test. This is 
done from the script list screen 1204 and through the use of reports. 

In a step 1310, the Test Administrator can make revisions to the 
scripts used in the specified test, such script revisions are made 
5 through sub-system YSCR. As previously mentioned, the Test 

Administrator can reinstate scripts, restart scripts, remove scripts, 
and create a next run of a script from script list 1204. 

In a step 1308, the Test Administrator monitors the tracking 
administrator workstation. Note that steps 1304, 1306, 1308, and 1310 
10 can interact dynamically with one another (indicated by arrows between 
the blocks in Fig. 13), and need not occur sequentially or in any 
particular order. 

The Test Administrator is given several options at step 1312. 
These are presented in script list 1204 and include restarting a script 
15 at any point prior to where the script was put on hold, reinstating the 
test from the point at which it was halted, removing a script from an 
operating test, or deleting a test in its entirety. The end of the test 
run in indicated at a step 1313. 



20 JL SCRIPT TRACKING SUB-SYSTEM f YTRK^ 

a. Purpose 

The script tracking sub-system (YTRK) is the section of SIS that 
facilitates the remote testing process. The script tracking sub-system 
automates and controls the testing process and allows for recording of 
25 all required information. 

The normal testing process includes: 1) selecting a script for 
testing, 2) running the test, 3) recording test results and any errors, 
and 4) passing the script on to the next workstation at the completion 
of the test at the current workstation. 
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b. Sub-svste m, Functions 

The script tracking sub-system according to the present invention 
provides functionality to SIS to automate and control the testing 
process, and to record all required information. FIG. 14 is a high- 
5 level functional diagram of the script tracking sub-system which 

illustrates the functions of this sub-system in terms of access screens 
and reports . 

From a test; selection screen 1402, a tester will specify which 
test, run, testcenter, and workstation are to be tested. The test can 
10 further select a script list 1404 (list of scripts currently assigned to 
the particular workstation or that need to be routed to that 
workstation) or a report menu 1418. Testing a script requires the 
tester to follow a controlled sequence of events. These events are 
outlined below. 

15 Script list screen 1404 provides the following functions: 

Check-Out-Script: This function assigns the script to 
the tester at a terminal of the logical workstation. Once a 
script has been assigned to a tester at a terminal, other 
testers are prevented from using that script to conduct a 

20 test. Once a script is checked-out, the tester performs the 

scenario choreographed by the script. 

Check-In-Script : This function tags the script as 
being completed at the current workstation. When the script 
is completed at a workstation and checked-in, tracking 

25 information is set up to enable the next workstation to 

check-out the script for testing. When the script is 
checked-in at the final workstation indicated in its routing 
section, the script is flagged as a completed script and 
will route to the test administrator. 

30 Hold Script: This function allows the tester to place 

the script "on hold" without the need to record an error. 
The script routes to the Test Administrator. 

Replace-in-Basket : This function allows a tester to 
return {to the workstation's "in basket") a script which he 
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has checked-ouc. This allows another tester within the 
logical workstation to execute the script. 

A scrolling and refresh-list function are also 
included {see block 1405) . 
5 Other functions available from script list 1404 include the 

following . 

Print Script Screen 1406: This function prints the contents of the 
script and all current document information as a report 1408. 

Record Documents Function 1410: Usually, a tester will have 
10 information to record at the completion of its portion of the test. 
This record documents function allows the tester to store this 
information so that it will be available to workstations that 
subsequently perform the test outlined in the script. From the record 
documents function 1410, the tester may also chose a change documents 
15 function 1412. Additional functions available from screens 1410,1412 
are shown in block 1413. 

Document History Function 1414: This function displays all 
documents and information currently recorded for a selected script. An 
SIR information report 1416 is generated by this function. Additional 
functions available from screen 1414 are shown in block 1415. 

SIR System 1409: The SIR system is used when the tester identifies 
an error within the results of the test. The SIR system flags the 
script with the error and records the information regarding the error. 
Depending on the severity of the error, the tester has the option to 
25 either -hold" or -continue" the testing process for chat script. in 
many cases, a tester will identify the same problem in different 
scripts, in such a case, the system provides the tester with an option 
to choose from a list of sir's that have been previously recorded. 

System Reports Menu 1416: This function allows the testers to 
monitor the progress of the test by generating various reports. These 
are listed below. 

- Script Print Parameter 1430: This function generates a script print 
report 1432. 



20 



30 
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- Document History Report 1420: This report produces a list of all 
documents (and related information) associated with a specified script 
within a test . 

- Document List Parameters 1426: This function generates a document 
5 list report 1428 which lists the documents generated during a test. 

- Script History/Forecast Report 1422: This report produces a history 
and forecast report for a script. The history portion of this report 
outlines where the script has been in a testing process. The forecast 
portion of this report indicates to which locations the script will go 

10 from the current time through completion of the test. 

- Test and SIR Statistics Report 1424: This report produces a 
statistical analysis of the number of SIR'S reported for a specified 
test. Information contained in this report includes the number of 
SIR'S, the status of each SIR , and which scripts were affected. 

15 Referring to FIG. 14, the functionality of the script tracking 

sub-system is now described. This functionality is described in terms 
of a tester participating in a test at a particular terminal. The 
general methodology followed by the tester is to view a list of scripts 
for testing, select a script to be tested, run the test according to the 

20 script, record test results, and then flag the script as having been 
completed at that workstation. 

When a tester invokes the script tracking sub-system, a test 
selection screen 1402 is presented. At the test selection screen 1402, 
the tester is given the option of selecting a test to be run, generating 

25 a selection of reports, or viewing the history of the workstation or of 
a script . 

If the tester chooses to run a test, a script list 1404 is 
presented to the tester. The script list 1404 provides a listing of all 
scripts which can be run by that particular workstation. This includes 
30 scripts that have already been run by a previous workstation and not run 
by the present workstation. 

At script list 1404, the tester can scroll through the list of 
scripts on the screen. From this list, the tester may select (check 
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out) a script to be tested, replace a script, hold a script, refresh a 
list on the screen, and check-in a script when completed. 

From script list 1404, the workstation user (that is, tester) may 
also print a script report 1408, record 1410 or change 1412 documents, 
print error information 1416, view document history 1414, or access the 
SIR system 1409. 

If the workstation user chooses to generate a script print report 
1408, the workstation user is presented with a script print parameters 
function 1406. From this screen, the workstation user can generate a 
script print report 1408. The script print report is a hard copy of the 
contents of the script selected and all current document information 
pertaining to that script. All current document information refers to 
documents recorded for the script for the current test, run and 
iteration, at previous and current workstations. 

If the tester chooses to record documents at the script list 1404, 
the workstation tester uses a record document function 1410. This 
stores any information generated during the test so that it is available 
to subsequent workstations. From record document function 1410, the 
tester can select a change documents function 1412 which allows a tester 
to post changes to previously recorded documents and information. Only 
those documents recorded at the current workstation are displayed and 
available for editing. 

If, from script list 1404, the tester chose the document history 
option, a document history function 1414 displays all documents and 
information currently recorded for the script. At this screen, the user 
can choose to generate an SIR information report 1416. The tester is 
provided with a capability of scrolling through the display at the 
document history screen. Finally, from script list 1404, the workstation 
user can invoke the SIR system 1418. 
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From test selection screen 1402, the tester may also choose to 
generate various sub-system reports. If such a selection is made, the 
tester is presented with a report menu 1418. From report menu 1418, 
numerous sub-system reports may be generated. The tester may choose to 
5 generate a document history list report 1420. Document history list 
report 1420 is a list of all documents and related information 
associated with a specified script within a test. 

The tester may also choose to generate a script history/forecast 
report 1422. Script history/ forecast report 1422 produces a history and 
10 a forecast report for a script. The history portion outlines where the 
script has been in a testing process. The forecast portion indicates 
remaining destinations for the script. 

Another report which may be generated from report menu 1418 is the 
Test and SIR statistics report 1424. As described above, Test and SIR 
15 statistics report 1424 provides a statistical analysis of the number of 
SIR'S reported for a specified test. 

The tester may choose to pull up a document list parameter 
function 1426 from report menu 1418. The document list parameter 
function 1426 allows the tester to specify document types or choose all 
20 documents to generate a document list report 1428. Document list report 
1428 produces a list of all documents generated during a test which 
match the type selected. 

Finally, the tester can select a script, print parameter function 
1430. Script print parameter function 1428 provides the tester with the 
25 opportunity to generate a script print report 1432. Script print report 
1432 is a printout of the contents of the script in a formatted style. 

As with other sub-systems in SIS , the functions of the script 
tracking sub-system are invoked using PFkeys or SAP function keys. 
These are shown on FIG. 14. 
30 c. Method of Script Tracking 

When a tester at a workstation sets out to execute a script, a 
general methodology is followed. FIG . 15 sets forth this methodology in 
the form of a flow chart. FIG. IS also illustrates script tracking at a 
works tac ion . 
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Referring to FIGS. 14 and 15, che cracking process will be 
described. In a step 1502, a tester views a list of scripts available to 
be run at the particular workstation. The list of available scripts 
appears on script list screen 1404. The scripts on this list are 
5 unavailable for use by other workstations until the present workstation 
has completed its test with the script. From this screen, in a step 
1504, the tester chooses to check-out a script to be followed. In other 
words, the tester selects a script from the script list. Once a script 
is checked-out by a terminal, it will no longer display on other 
10 tester's lists, to avoid more than one tester checking-out the sajne 
script . 

In a step 1506, the tester may choose to print the script that has 
been selected for testing. This will provide the tester with a hard 
copy of the script and documents recorded for the script to be followed 
15 during the test. 

In a step 1508, the tester runs the test as outlined in the script 
selected. The script gives the tester information to be entered at the 
workstation and the expected results. If a problem is detected at step 
1409 (during test execution), then the problem is handled as discussed 
20 below in steps 1516 and 1518. If, however, no problems are encountered, 
then the test results are recorded in a step 1510. This step provides a 
history of the documents that have been recorded for the particular 
script . 

In a step 1512, the tester checks-in the script from script list 
25 screen 1404. Checking-in the script removes the script from the current 
workstation and displays the script at the next workstation on the 
script routing. The script is then available for use by the next 
workstation . 

The tester then has the option of viewing the history of the test 
30 conducted at that workstation at a step 1514, before proceeding to 
process another script at step 1502 . 
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If a problem was detected at step 1409, then the tester records an 
SIR at step 1516 and the SIR document number is automatically recorded 
into SIS at step 1518. If the script cannot continue and is held, this 
marks the completion of the test for that particular script and the 
5 tester may proceed with a new script at step 1502. If the script can 

continue, then the tester continues processing the script at either step 
1508 or 1510, depending on where the problem was encountered. 

VT CONCLUSION 

10 In general the present invention includes a system and method for 

defining testing scenarios for a multi-user computer system with a 
plurality of workstations, and for driving and tracking the execution at 
the workstations of the testing scenarios in a predefined order. In a 
preferred embodiment of the present invention, the testing revolves 

15 around the concept of a 'script-. A script includes instructions and 
data necessary to simulate the functionality to be tested. 

While the invention provides an efficient testing tool, the 
inventors contemplate the invention may be further improved by the 
incorporation of a keystroke recording means to simulate a user 

20 interface. A keystroke recording and playback means would remove the 
requirement that testers (that is, users present at each workstation to 
act out the instructions in each script) be used. The keystroke 
recording and playback means would perform all functions performed by 
the testers except for, possibly, verifying test results. An example of 

25 a keystroke recording and playback means which may be suitable/adaptable 
for such a purpose is PlayBack, available from Compuware Corporation, 
Farmington Hills, Michigan. 

While preferred embodiments of the invention have been described, 
various modifications, alterations, and changes may be made without 

30 departing from the spirit and scope of the present invention as defined 
in the appended claims. 
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1. A computerized method for testing a multi-user computer 
system including a plurality of workstations, the method comprising the 
steps of: 

5 (1) creating a plurality of scripts, wherein each of said 

plurality of scripts contains instructions, data and routing 
information, said routing information being indicative of the 
workstations to which a script should be routed and in what order; 

(2) grouping selected ones of said scripts to form a test, 
10 (3) initiating a test run, 

(4) routing said selected ones of said plurality of 
scripts to selected ones of the workstations according to said routing 
information;' and 

{5) monitoring routing of said scripts from workstation 
15 to workstation. 

2. The method of claim 1, wherein the method further 
comprises the step of 

(6) automatically documenting the test results. 

20 

3. The method of claims 1 or 2, further including after (5) 

the step of 

(5.1) in an error situation, selectively controlling routing 
of said scripts from workstation to workstation. 

25 

4. The method of one of claims 1-3, further including the 

step of 

assigning a selected one of said plurality of scripts to a 
first terminal of a first workstation in response to a first command 
30 from said first terminal. 
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5. The method of claim 4, further including the step of 
displaying said instructions contained in said selected one 

of said plurality of scripts at said first terminal in response to a 
second command from said first terminal. 

5 

6. The method of claim 4, further including the step of 
receiving and recording test results from said firsc 

terminal . 



10 7. The method of claim 6. further including the step of 

transferring said selected one of said plurality of scripts 
from said first workstation to a second workstation in response to a 
third comand from said first terminal and in accordance with said 
routing information in said selected one of said plurality of scripts. 

15 

8. The method of one of claims 1-7, further including the 

step of 

automatically generating the routing information for a 
selected one of said plurality of scripts based upon said instructions 
20 in said selected one of said plurality of scripts. 



9. The method of one of claims 1-8, further including the 

steps of 

setting a status code, a blocking indicator and a category 
25 indicator for a selected group of said plurality of scripts and for 
copying and deleting selected ones of said plurality of scripts. 

10. The method of one of claims 1-9, further including the 

step of 

30 generating statistical reports documenting execution 

statistics for the test. 
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11. A computerized method for testing a multi-user computer 
system which includes a plurality of workstations, wherein a plurality 
of scripts which are used to create a test have been created and each 
script contains instructions, data and routing information, said routing 

5 information being indicative of the workstations to which a script 
should be routed and in what order, the method comprising: 

(1) initiating a run of the test in response to a command 
entered via one of the plurality of workstations; 

(2) routing a selected one of the plurality of scripts to 
10 a selected one of the plurality of workstations as indicated in the 

routing information of said selected one of the plurality of scripts; 

(3) executing at said selected one of the plurality of 
workstations a portion of the test in accordance with the instructions 
contained in said selected one of the plurality of scripts in response 

15 to a command of a user entered via said selected one of the plurality of 
workstations; 

(4) transferring said selected one of the plurality of 
scripts to a next selected one of the plurality of workstations as 
indicated in the routing information of said selected one of the 

20 plurality of scripts in response to a command from said selected one of 
the plurality of workstations; and 

(5) repeating step (2) through (4) for each of the 
plurality of scripts until each said selected one of the plurality of 
scripts has been transferred in order to each workstation as indicated 

25 in the routing information. 

12. The method of claim 11, wherein step (3) further 

comprises 

recording test results input at said selected one of the 
30 plurality of workstations. 
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13. The method of claims 11 or 12, wherein step (3) further 

comprises 

recording error information input at said selected one of 
the plurality of workstations when an error is detected during the 
execution of said portion of the test. 

14. The method of one of claims 11-13, further including 
between step (3) and step (4) the step of 

selectively controlling the transfer of said selected one of the 
plurality of scripts in response to a command entered via one of the 
plurality of workstations. 



15. A computerized testing system for a multi-user computer 
system including a plurality of workstations coupled to a central compu- 

15 ter, and a database configured to store scripts, wherein each of said 
plurality of scripts contains instructions, data and routing 
information, said routing information being indicative of the 
workstations to which a script should be routed and in what order, 
comprising: 

20 (!) maintenance and creation means for creating and 

modifying said plurality of scripts; and 

(2) tracking means for routing selected ones of said 
plurality of scripts to selected ones of said plurality of workstations 
according to said routing information. 

25 

16. The testing system of claim 15, further comprising 
(5) tracking administration means for grouping selected 

ones of said scripts to form the test, initiating a test run, and 
monitoring and, in an error situation, selectively controlling routing 
30 of said scripts from workstation to workstation. 
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17. The testing system of claim 16, wherein said cracking 
administration means further comprises 

means for automatically generating statistical reports 
documenting execution statistics for the test. 

18. The testing system of one of claims 15-17, further 

comprising 

script administration means for copying and deleting groups 
of scripts, limiting access to scripts and updating groups of scripts. 

19. Use of the system of one of claims 15-18 for the method 
of one of claims 1-14. 



20. Multi-user commuter system including a plurality of 
15 workstations coupled to a central computer, and a data base configured 
to store scripts, wherein each of said plurality of scripts contains 
instructions, data and routing information, said routing information 
being indicative of the work stations to which a script should be routed 
and in what order, comprising: 
20 a testing system of one of claims 15-19. 



21. Workstation for a multi-user computer system including 
a plurality of workstations coupled to a central computer, and a data 
base configured to store scripts, wherein each of said plurality of 
scripts contains instructions, date and routing information, said 
routing information being indicative of the workstations to which a 
script should be routed and in what order, comprising: 

a part of a testing system of one of claims 15-19. 
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